The present invention relates to the control of a client computer system""s Medium Access Control (MAC) address by a server computer system.
A computer or computer system, when turned on, must be prepared for operation by loading an operating system. In the normal operation of a single computer system, when a user issues a boot command to the computer, the computer responds to the boot command by attempting to retrieve the operating system files from the computer systems memory. Configuration data files are also needed to configure the specific machine with the hardware parameters necessary for the specific hardware configuration. These files also contain information needed to initialize videos, printers, and peripherals associated with the particular machine. For example, the files would include CONFIG.SYS in the MS-DOS operating system, available from Microsoft Corporation.
Computers or computer systems can be connected in a network normally consisting of a client workstation, a server and a central network. In a system where the computer""s storage is maintained when the power is turned off, the operating system can be stored in the computer itself. In a system where the computer has only storage that is lost when the power is turned off, the computer cannot retrieve the boot information from within the computer itself. In that case, the client sends a request for the operating system files via the network to the server acting as a boot server. Even when the client workstation has non-volatile storage capability, it is advantageous to boot from the server because memory space is saved in the workstation computer. As operating system and application programs expand to provide new and greater capabilities, booting from a server can be highly advantageous.
Several methods of remote booting exist in the marketplace. One is called Remote Initial Program Load (RIPL). RIPL is the process of loading an operating system onto a workstation from a remote location. The RIPL protocol was co-developed by 3Com, Microsoft, and IBM. It is used today with IBM OS/2 Warp Server, DEC Pathworks, and Windows NT. Two other commonly used Remote IPL protocols are a Novell NCP (NetWare Core Protocol), and BOOT-P, an IEEE standard, used with UNIX and TCP/IP networks.
RIPL is achieved using a combination of hardware and software. The requesting device, called the requester or workstation, starts up by asking the loading device to send it a bootstrap program. The loading device is another computer that has a hard disk and is called the RIPL server or file server. The RIPL server uses a loader program to send the bootstrap program to the workstation. Once the workstation receives the bootstrap program, it is then equipped to request an operating system, which in turn can request and use application programs. The software implementations differ between vendors, but theoretically, they all perform similar functions and go through a similar process. The client workstation requires a special Read Only Memory (ROM) installed on its (Local Area Network) LAN adapter or Network Interface Card (NIC). The special ROM is known generally as a remote boot ROM, but two specific examples of remote boot chips are the RIPL chip, which supports ANSI/IEEE standard 802.2, and the Preboot Execution Environment (PXE) chip, which is used in the Transmission Control Protocol/Internet Protocol (TCP/IP) environment.
While the process has many advantages for booting a computer that has volatile storage, such as a network computer, the computer is required to have a remote boot ROM on the LAN adapter or Network Interface Card (NIC). The remote boot ROM requirement does not allow any user interaction with the remote boot process.
Application Ser. No. 09/329,457 discloses a remotely controlled boot process allowing a client computer to boot from a server without the remote boot ROM requirement.
The client""s Medium Access Control (MAC) address is the key factor that determines many characteristics of the boot process. The MAC address determines what server the client will boot from, what operating system will be loaded and what the client""s computers configuration will be.
However, in the server-managed client environment, there currently does not exist a way to automatically assign and configure a client""s MAC address. The MAC address can be a Universally Administered Address or a Locally Administered Address. The Universally Administered Address (UAA), in a local area network, is the address permanently encoded in an adapter at the time of manufacture. All Universally Administered Addresses are unique. A Locally Administered Address (LAA), in a local area network, is an adapter address that the user can assign to override the Universally Administered Address. Therefore, a need exists for an automatic way of configuring and distributing a Locally Administered Address (LAA). If this can be done, then when the boot configuration is changed, an address corresponding to the configuration desired can be assigned. Such a system would provide a seamless solution in dynamically changing a client""s boot environment and would greatly expand the ability of the administrator to remotely configure the client machines within a network.
The invention meeting the needs identified above is a method and apparatus for Dynamic MAC Allocation and Configuration. Such a system is based on the ability to remotely boot a client machine from a server machine and adds the capability to assign a Locally Administered Address (LAA) to override the Universally Administered Address (UAA).
The first part of the process is to set up the capability for remote booting. In the preferred embodiment, a set of programs at the workstation allows a remote boot and interaction with a program on the server. Instructions from a Basic Input Output System (BIOS) ROM are executed to load a Boot Code Loader (BCL) from a nonvolatile, read/write memory, such as a diskette or hard disk. The BCL executes to load a Remote Control Program (RCP), and the RCP executes to load a message program, a protocol manager and/or device drivers without loading an operating system. The message program and/or device drivers communicate with a Dynamic Mac Allocation and Configuration (DMAC) program in the network server. First, the program will interface with an NDIS compliant Network Interface Card (NIC) to send out a DMAC discovery frame. At this point the workstation seeks MAC specific information. The discovery frame will be intercepted by a DMAC program installed on the server which will be running and listening for the request. Once the DMAC program intercepts the request it will analyze the request and take one of two actions. First, if this is the first time that the client machine has been booted, the server will run an xe2x80x9cinitializationxe2x80x9d script. In other words the DMAC will prepare the other boot servers by informing them that in the future, the workstation in question will boot. The workstation will be placed in a MAC table or pool. The second action, for workstations that have already been initialized, is that the server, based on the information received, will send an LAA to the client workstation from the table or pool. The client workstation will then request an operating system with its new LAA. The boot options will be a table or pool corresponding to an LAA or range of LAA""s. In other words, a particular boot option or package will be sent to a system making a request that has the corresponding LAA. In order to achieve the override of the UAA, the DMAC will assign an LAA to the workstation. Once the LAA is assigned the boot will proceed based on the package that will be shipped to that address.